Skip to content

feat(mobile): hide the play bar with the rest of the bottom chrome - #14577

Merged
dylanjeffers merged 1 commit into
mainfrom
feat/mobile-playbar-autohide
Aug 25, 2026
Merged

feat(mobile): hide the play bar with the rest of the bottom chrome#14577
dylanjeffers merged 1 commit into
mainfrom
feat/mobile-playbar-autohide

Conversation

@dylanjeffers

Copy link
Copy Markdown
Contributor

Follow-up to #14575. The now-playing bar didn't participate in the auto-hide, so scrolling down with a track playing left it stranded — the tab bar floats away beneath it and the play bar stayed put with an empty band underneath.

It now travels on the same useTabBarHiddenProgress the tab bar uses, so the two move as one unit rather than on two signals that can drift.

Why the whole drawer moves, not the play bar

My first attempt translated just the play bar. Both bars hid — and it left an empty white band instead. The white surface behind the play bar belongs to the drawer root, so moving only its contents slid the bar off a background that stayed put. Same problem, different colour.

So this moves the drawer. Two consequences worth reviewing:

  • Wrapping the drawer creates a new stacking context, so its z-order is restated on the wrapper, and pointerEvents='box-none' keeps the full-screen wrapper from swallowing touches meant for the screen behind it. This is the same class of thing the tab bar work already had to handle.
  • Pinned to 0 while the drawer is open — that same drawer is the full-screen player, and translating it there would drag the expanded player off screen.

Verification (iOS simulator, track actually playing)

  • Chrome hides and restores as one unit, no empty band.
  • Full-screen player still opens correctly through the wrapper.
  • Swipe-to-dismiss still works.
  • Left nav drawer still pushes the play bar with the screen rather than being punctured by its elevation — the specific z-order risk of wrapping.
  • No crashes across the run.

tsc 0 errors, eslint clean.

Not verified

Android. This is a shared, gesture-heavy component and Android resolves z-order via elevation rather than zIndex, which is exactly where the wrapper could behave differently. Worth an Android check before or shortly after merge.

Unrelated, but noticed

Two SIGABRTs occurred on the simulator during this session, both ShadowTree::commit asserts inside reanimated::ReanimatedMountHook::shadowTreeDidMount. Both followed Fast Refresh reload cycles; clean launches have been stable through playback, scrolling, drawer open/close and tab switching. Likely a dev-only artifact — that assert is typically compiled out in release — but noting it since it first appeared during the #14575 reanimated work rather than before it.

🤖 Generated with Claude Code

The now-playing bar did not participate in the auto-hide, so scrolling down
with a track playing left it stranded: the tab bar floats away beneath it and
the play bar stayed put with an empty band underneath.

It travels on the same `useTabBarHiddenProgress` the tab bar uses, so the two
move as one unit rather than on two signals that can drift apart.

This translates the whole drawer, not the play bar inside it. The white surface
behind the play bar belongs to the drawer root, so moving only its contents
slides the bar off a background that stays put — trading the empty band for an
empty white block. Wrapping the drawer means restating its z-order, since the
wrapper creates a new stacking context, and `box-none` so the full-screen
wrapper doesn't swallow touches meant for the screen behind it.

Pinned to 0 while the drawer is open: the same drawer is the full-screen
player, and translating it there would drag the expanded player off screen.

Verified on the iOS simulator with a track playing — chrome hides and restores
as one unit with no empty band; the full-screen player still opens, still
swipe-dismisses, and the left nav drawer still pushes the bar with the screen
rather than being punctured by its elevation.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@changeset-bot

changeset-bot Bot commented Aug 25, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: e3643fc

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@dylanjeffers
dylanjeffers merged commit 9a76664 into main Aug 25, 2026
3 checks passed
@dylanjeffers
dylanjeffers deleted the feat/mobile-playbar-autohide branch August 25, 2026 01:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant